home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc17.txt < prev    next >
Text File  |  1994-08-01  |  4KB  |  107 lines
  1. Network Working Group                        John E. Kreznar
  2. RFC-17                                SDC
  3.                                 27 August 1969
  4.  
  5.  
  6.  
  7. Some Questions Re:  HOST-IMP Protocol
  8.  
  9.  
  10. l.  Automatic deletion of links, as indicated in BBN 1822, page 11, seems
  11.     bad:
  12.  
  13.     a)  Link use may be dependent upon human use of a time share terminal -
  14.     indefinite time between messages.
  15.  
  16.     b)  Program using link may be slow due to:
  17.  
  18.      i)  Bush HOST (many jobs)
  19.  
  20.     ii)  Much local I/O and/or CPU time between messages - is it that,
  21.          if a HOST's user failes to use a link for 15 seconds, the HOST
  22.          network program must generate a dummy message merely to keep
  23.          the link open?
  24.  
  25. 2.  Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2:  "Can a HOST,
  26.     as opposed to its IMP, control RFNM's?"  BBN, Report No. 1837, 1969 Jul,
  27.     says on page 2:  "The principal function of the (IMP) program...includes
  28.     ...generating of RFNM's..."  What if an IMP generates an RFNM and then
  29.     discovers it cannot, for some reason, complete timely delivery of the
  30.     last received message to its HOST?  This seems especially pressing since
  31.     I can't recall seeing anywhere an IMP constraint upon HOSTs that they
  32.     must accept incoming messages within some specified maximum time.
  33.  
  34. 3.  A HOST has to be prepared to repeat transmissions of a message into
  35.     network (see, e.g., Page 17, BBN 1822) therefore why the special
  36.     discardable NOP message (Page 12, BBN 1822).
  37.  
  38. 4.  "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems inconsistent
  39.     with automatic link deletion questioned in 1 above.  Normally the times
  40.     involved differ by many orders of magnitude but a high priority nonnetwork
  41.     HOST responsibility could delay next bit for a long time.
  42.  
  43.     1.  Abhi Bhushan, Proj. MAC    10.  Sal Aranda, SDC
  44.     2.  Steve Crocker, UCLA        11.  Jerry Cole,  "
  45.     3.  Ron Stoughton, UCSB        12.  John Kreznar,"
  46.     4.  Elmer Shapiro, SRI        13.  Dick Linde,  "
  47.      5.  Steve Carr, Utah        14.  Bob Long,    "
  48.     6.  John Haefner, RAND        15.  Reg Martin,  "
  49.     7.  Paul Rovner, LL        16.  Hal Sackman, "
  50.     8.  Bob Kahn, BB&N        17.  C. Weissman, "
  51.     9.  Larry Roberts, ARPA
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
  62.             WHICH WERE RAISED  NWG: - 17
  63.  
  64.  
  65.  
  66. The deletion of a link entry from an IMP's link table will, in general,
  67. have no effect upon a Host transmission (or reception) at that IMP's
  68. site.  Let us distinguish between nonuse of a link in-between messages
  69. and nonuse of a link due to Host program delays in the middle of 
  70. transmitting or receiving a message.  When the Host transmits a message
  71. on a link for which an entry is not in the link table, one will simply be
  72. inserted there.  There is no need for "dummy" Host messages to keep a link 
  73. "open" since a link is effectively always open.  Only if the link table
  74. becomes full immediately after an entry is deleted (a situation we do not
  75. expect to occur) is there a possibility of resulting delay.
  76.  
  77. Arbitrary delays introduced by Host programs are also not inconsistent
  78. with the link entry delection procedure.  A link is blocked when the first
  79. access of the link table is made during transmission from the source IMP
  80. and is unblocked when the RFNM returns.  Only nonblocked transmit link
  81. entries are deleted after 30 seconds of disuse.  The statement on page 23 
  82. referencing arbitrary delays was only intended to have hardware implications
  83. insofar as the Host/IMP interface is designed to transfer bits asynchronously
  84. betweem the Host and the IMP.
  85.  
  86. A RFNM is returned from the destination IMP to the source IMP when a
  87. message reaches the head of the destination IMP's output queue to the Host
  88. (i.e., just before a message is sent to the Host).  If a destination IMP
  89. cannot then deliver that full message to the Host, at most one more message
  90. may possibly arrive at that IMP due to the premature release of the RFNM.
  91. The new message will subsequently take its place at the end of the output
  92. queue to the Host thus guaranteeing the preservation of the proper message
  93. arrival sequence.
  94.  
  95. The NOP message is a special control message which is available for use
  96. during initiation of communication between the Host and its IMP.  The Host
  97. may, of course, decline to send NOP messages during this period, but the
  98. first received message after IMP startup or after the Host ready indicator
  99. has gone on, may be discarded by the IMP.  We do not require a Host to be 
  100. prepared to repeat transmissions into the network.
  101.  
  102.  
  103.  
  104.  
  105.  
  106. R. E. Kahn
  107. BOLT BERANEK AND NEWMAN INC.